home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15463 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.3 KB  |  117 lines
  1. Path: news.sprintlink.net!datalytics!usenet
  2. From: Rob Stewart <stew@datalytics.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Another class/function pointer problem...
  5. Date: Fri, 05 Apr 1996 11:52:41 -0500
  6. Organization: Datalytics, Inc
  7. Message-ID: <31654FD9.1F6E@datalytics.com>
  8. References: <315FE1D1.E66@cs.utwente.nl>
  9. NNTP-Posting-Host: 204.62.224.71
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. Angelo Starink wrote:
  16. > 
  17. > Since I tried to use a callback function within an object, I'm
  18. > suffering from the class/function pointer problem as well...
  19. > 
  20. > Using the "static" trick it seemed like the problem was solved
  21. > but now I can't get reach my class member variables:
  22. > 
  23. > class Problem {
  24. > public:
  25. > 
  26. >         static CALLBACK void fn(...,...,..);
  27. >         HWND the_window_using_this_object;
  28. > 
  29. > };
  30. > [snip]
  31. > When I try to compile this, Visual C++ 2.0 says:
  32. > "'Problem::the_window_using_this_object' does not specify an object"
  33. > 
  34.  
  35. Your problem is that the HWND is a dm of class Problem.  There 
  36. is a separate the_window_using_this_object in each Problem 
  37. object.  A static mf has no this pointer and is not associated 
  38. with a particular Problem instance as a result.
  39.  
  40. One way to make this work is to make 
  41. the_window_using_this_object a static dm.  Then, fn can access 
  42. it.  This approach means there can be only one window associated 
  43. with the callback at a time.
  44.  
  45. class Problem
  46. {
  47.    public:
  48.       static CALLBACK void fn(...);
  49.    private:
  50.       static HWND m_hWindow;
  51. };
  52.  
  53. CALLBACK void Problem::fn(...)
  54. {
  55.    ::MessageBox(
  56.       m_hWindow,
  57.       "Whatever...",
  58.       "Don't care",
  59.       MB_OK);
  60. }
  61.  
  62. The only other solution is to save the current object's this 
  63. pointer in a static dm and then access 
  64. the_window_using_this_object through it.  This approach has the 
  65. advantage of having an object associated with each interested 
  66. window, and the object is associated with the callback only 
  67. until the callback is invoked.
  68.  
  69. class Problem
  70. {
  71.    public:
  72.       static CALLBACK void fn(...);
  73.       void                 RegisterCallback(void);
  74.    private:
  75.       HWND  m_hWindow;
  76.  
  77.       static Problem*   s_pThis;
  78. };
  79.  
  80. inline
  81. void Problem::RegisterCallback(void)
  82. {
  83.    ASSERT(!s_pThis);
  84.    s_pThis = this;
  85. }
  86.  
  87. CALLBACK void Problem::fn(...)
  88. {
  89.    Problem* pThis = s_pThis;
  90.    s_pThis = 0;
  91.    ::MessageBox(
  92.       s_pThis->m_hWindow,
  93.       "Whatever...",
  94.       "Don't care",
  95.       MB_OK);
  96. }
  97.  
  98. Both solutions raise the spectre of multithreaded safety.  As 
  99. soon as you introduce static dms into a class, you have to 
  100. protect access to them in a multithreaded application.  You can 
  101. protect access several ways.  One way relegates all access to a 
  102. single thread.  By convention, you simply avoid accesses in any 
  103. other thread.  This is safe, provided it is well documented and 
  104. it is easy to determine the thread from which you are accessing 
  105. these objects.
  106.  
  107. Another means to make the accesses thread safe is to protect 
  108. them with an NT critical section, mutex, or semaphore.  The 
  109. logical thing would be to have RegisterCallback lock access to 
  110. the static dm, and (probably) have fn release the lock.  Then, 
  111. you serialize setting and responding to the data stored in the 
  112. static dm.
  113.  
  114. -- 
  115. Robert Stewart        | My opinions are usually my own.
  116. Datalytics, Inc.    | stew@datalytics.com
  117.